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(57) Abstract: The invention relates to a system, enabling subscribers of a wire less Telecom ( )perator to execute financial transac- 
tions with a mobile phone, or an electronic device which can be connected to the wireless communication network, characterised in 
that a subscriber has one or several Financial Transaction Accounts open and managed by the Telecom Operator, which can receive 
monetary deposits, and on which debit and credit operations can be executed. The system is composed of a Transaction Process- 
ing Platform, which is installed on the computers of the Telecom Operator, is connected to the wireless communication network, is 
interfaced with other elements of the Telecom Operator, manages the Financial Transactions Accounts, verifies/executes financial 
ininsaelions sent by the subscribers, and executes other tasks like confirmations of transactions, account statement preparation, re- 
porting, etc... The system is also composed of a client software that runs on the Mobile Phone of the subscriber or his connectable 
electronic device or on the Subscriber Identify Module (SIM for GSM, UIM for CDMA, USIM for 3G UMTS, etc ) which is in- 
serted in the mobile phone or connectable electronic device. Such client software enables the subscriber to prepare, validate and 
send through the wireless communication network, transactions orders to the Transaction Processing Platform. 
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SYSTEM TO ENABLE A TELECOM OPERATOR PROVIDE FINANCIAL 
TRANSACTIONS SERVICES AND METHODS FOR IMPLEMENTING 
SUCH TRANSACTIONS 

TE CHNICAL FIELD 

5 

The invention relates to a wireless telecommunication system, and more particularly to a 
system which enables a wireless telecom operator provide financial transactions services; 
and methods for implementing such transactions through a wireless communication 
network. 

10 BACKGROUND OF THE INVENTION 

The development of networks, like Internet, has been instrumental in the emergence of 
new concepts like Electronic commerce. However Electronic payment systems have been 
lagging behind such recent developments, and today all attempts to implement Electronic 

15 digital payment systems have faced the challenges to be really: simple, effective, user 
friendly, secure, scalable, easy to deploy, etc... In most case digital payment systems do 
require the implementation of complex architecture and the intervention of many parties 
and especially financial institutions, like banks or others. Further more the 
implementation of such system generally required the installation of dedicated 

20 infrastructure, making them difficult to deploy massively among consumers. Digital 
systems have already enjoyed a great success in the telecommunication sector and in 
particular with mobile telephone systems like GSM, CDMA and W-CDMA, CDMA2000 or 
others. Those systems are providing consumers with more and more capabilities and 
performances. As such those systems have become, in just few years, extremely popular, 

25 and a significant part of the population is now using consistently digital mobile phones, 
not only for voice but also for data transfer. Digital mobile phone has become a natural 
or even indispensable companion for many people; and it is naturally envisaged to 
extend its use through this invention. 



30 SUMMARY OF THE INVENTION 

The object of this invention is to bring a solution to the complexity issue of electronic 
financial transactions implementation. 

35 This invention describes an innovative system which will enable a wireless telecom 
operator provide financial transactions services to its subscribers. The invention is 
characterised by the fact that the system does not require the implication of any financial 
institution (bank, savings bank, credit card organisation, or other); does not require the 
installation of a dedicated network infrastructure, does not need the use of other 

40 traditional means of payment like credit cards or debit cards; does not require the use of 
special devices by the subscribers; but rather makes full use of one operator's existing 
wireless communication network and system, as well as existing mobile phones. It is 
characterised by the fact that the Telecom Operator open and manages Financial 
Transaction Accounts for its subscribers and provide them with tools and rights to 

45 execute from their mobile phone or connectable electronic device, financial transactions. 
Since the Financial Transactions Accounts, the methods and corresponding tools are 
operated and controlled by one single actor, the Telecom Operator, this simplifies greatly 
the system and its security architecture. It also avoid conflicts of interests between 
otherwise, multiple parties. 

50 

The system is composed of a Transaction Processing Platform, which is installed on the 
computers of the Telecom Operator, is connected to the wireless communication network, 
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is interfaced with other elements of the Telecom Operator system (Subscriber's data base, 
authentication centre, accounting system, etc.), manages the Financial Transactions 
Accounts, verifies/executes financial transactions sent by the subscribers, and executes 
other tasks, like confirmations of transactions, account statement preparation, reporting, 
5 etc... This platform implements the methods for executing the financial transactions 
which are described in this invention. 

The system is also composed of a client software that runs on the mobile Phone of the 
subscriber or his connectable electronic device, or on the Subscriber Identity Module 
10 (SIM for GSM, UIM for CDMA, USIM for 3G UMTS, etc..) which is inserted in the mobile 
phone or connectable electronic device. Such client software enables the subscriber to 
prepare, validate, sent through the wireless communication network, transactions orders 
to the Transaction Processing Platform, according to such methods which are described in 
this invention. 

15 

This system allows the subscribers to execute those transactions, such as payment to 
another person, payment to a merchant etc... in a simple, secure, and user friendly way 
by using their digital mobile phone or electronic equipment connected to the wireless 
communication network. The benefits of such system are easy to imagine. But it can 
20 bring new possibilities which today do not exist yet, like for example: 

- Instant payment by millions of people to one single organisation: this would the case 
for a donation campaign organised around a TV show. By displaying one single 
number on the TV (on which to donate), a large number of viewers can use their 
mobile phone to make a donation, while the donation organiser can follow in real time 

25 the results... 

- Possibility to make payment to a party in an anonymous way. 

- Possibility to make payment to an unknown party, which will only be identified by a 
number. 

This system and methods for executing financial transactions do represent an innovative 
30 alternative to existing means of payment, be cash, credit or debit cards, checks, money 
transfer, as they cumulate in one single solution advantages of all those means. 



BRTEF DESCRIPTION OF DRAWINGS 

35 The invention will be described more in detail below with reference to the appended 
drawings, in which: 

Figure 1 is a representation of the system overview and how the Transaction Processing 
platform is connected to the wireless communication network and interfaced with the 
Telecom Operator sub-systems. 
40 Figure 2 shows the flow chart of transaction scenariol as described in details below; it 
represents the different steps. On the right side icons illustrate where the tasks are 
performed: Mobile Phone, TPP. 

Figure 3 illustrates the different screen displays on Payer's Mobile Phone which are 
mentioned in Figure 2. 

45 Figure 4 illustrates the different screen displays on Payee's Mobile Phone which are 
mentioned in Figure 2. 



DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 

50 

This invention is characterised by the fact that the Telecom Operator provides the 
subscribers with a Financial Transaction Account (FTA). This Financial Transaction 
Account is very much like a current account in a bank, and allows its owner to make 
deposits, receive payments and money transfers from third parties, execute payments to 
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third parties, have overdraft facility, get credit, etc... An FTA Agreement is signed 
between the Telecom Operator and the subscriber, and defines the terms and conditions 
of use. Those conditions may include but are not limited to: general conditions of use of 
FTA, minimum balance, credit or overdraft limits, interest charges, interests earned on 
5 deposits, transactions values limits, service and transaction charges, billing conditions, 
discounts on transactions volumes, privacy, anonymity of payments, credit redemption, 
credit reload, pre-payment, etc... 

Opening a Financial Transaction Account is an easy process since each subscriber is 
already clearly identified by the Telecom Operator's system with a series of personal data 
10 such as: name, address, ID card number, Bank account number, etc... 

As the result of his subscription, the subscriber gets a unique Mobile Phone Number 
which is directly linked to his Phone Account in the billing and accounting system of the 
Telecom Operator. 

This invention is characterised by the fact that the "Mobile Phone Number" of a 
15 subscriber is also used to identify his Financial Transaction Account. As such the 
subscriber only needs to mention his Mobile Phone Number to receive payment 
transactions from third parties directly on his FTA. 

In an alternate embodiment of the invention the Telecom Operator provides a special 
number (different from the Mobile Phone Number) for the Financial Transaction Account: 
20 "FTA Number". This is particularly convenient when the subscriber wants to keep a 
certain level of privacy and does not want to disclose his Mobile Phone Number to too 
many people. 

As such a subscriber who wants to register to the Financial Transaction service will have 
25 two accounts, one Phone Account where his mobile phone activity is logged, and one 
Financial Transaction Account dedicated to his deposits and financial transactions 
settlement. 

In an alternate embodiment of the invention the Phone Account and the Financial 
Transaction Account are merged in one single account. This is particularly useful in case 
30 of Prepaid Telephone Account. This allows the Telecom Operator to provide "debit only" 
financial transaction service capability to a prepaid subscriber. 

The subscriber will then be able to execute financial transactions from in a simple way 
using his mobile phone and methods which are described further in this document. 

35 

In an alternate embodiment of the invention, the subscriber can use other mobile 
equipments than his Mobile Phone; those equipments can be, but are not limited to: 
personal computer, PDA, organiser, pocket computer, a digital camera, or any other 
electronic equipment with a capability to be identified and connected to the wireless 
40 communication network of the operator. Further below those equipments are called 
"connectable electronic devices". 

This invention is also characterised by the fact that the system is composed of the 
following elements or sub-systems: 

45 

A software platform: the Transaction Processing Platform (TPP) 

The invention is characterised by the fact that this platform can either run on the existing 
computers of the Telecom Operator, or on a dedicated computer. It is connected to, and 
50 interfaced with, some key elements of the operator's wireless system, such as but not 
limited to: the subscribers' database, the authentication module, the various data 
channels, the billing system, the accounting system, internet, etc... 
This platform is at the heart of the system, and performs a series of functions such as 
but not limited to: 

55 . Receiving through a data channel and interpreting transaction orders from mobile 
phones 
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. Receiving through the data channel and interpreting information or account status 
requests 

. Processing transactions (executing the relevant credit and debit operations on the 
various accounts) 
5 . Settling transactions 

. Selecting adequate data channel to send and/or receive data to/from mobile phones 
. Sending transaction notices, confirmations, or refusal to the relevant parties 
. Sending FTA status to his owner 

. Managing, updating, modifying FTA conditions and parameters as a result of 
10 commercial conditions established between the Telecom Operator and the subscriber 

. Charging, invoicing, processing the transaction fees to the relevant parties and 

according to terms and conditions of each FTA 

. Establishing FTA statements 

. Establishing account ledger, and accounting 
15 . Providing online report for FTA owners 

. Generating automatically alerts and advices, 

. Generating and sending printed reports like statement of account, transactions notices, 
accounting reports, etc... 

20 A client software program: Mobile Transaction Management Software (MTMS) 

This invention is characterised by the fact that a client software is stored either in a 
memory of the mobile telephone or connectable electronic device, or a memory the 
Subscriber's Identity Module (SIM card for GSM, or UIM card for CDMA, USIM card for 3G 
25 UMTS, or equivalent), and able to be executed by one of the microprocessors of the 
mobile phone or connectable electronic device or by the microcontroller of the SIM or by 
both the SIM and the processor of the mobile phone or connectable electronic device. 

This client software enables the execution of financial transactions from the Mobile Phone 
30 or connectable electronic device according to the methods described below. It also 

enables to retrieve information on the status and situation of the Financial Transaction 

Account. For this purpose it performs a series of functions such as but not limited to: 

. Displaying information in a structured manner on the Mobile Phone or connectable 

electronic device screen to prompt the subscriber for actions 
35 . Generating screens and fields for transaction data capture 

. Prompting password input 

. Authenticating the subscriber 

. Preparing data file of a transaction 

. Encrypting (when needed) transaction related data files 
40 . Generating digital signature of transaction related data files 

. Detecting the most appropriate data channel to be used according to the mobile phone 

or connectable electronic device capabilities, and transaction data characteristics (size, 

priority, etc..) 

. Sending through the chosen data channel, the transaction data file to the Transaction 
45 Processing Platform 

. Managing the Financial Transaction Service parameters at the level of the Mobile Phone 
or connectable electronic device 

. Managing the activation or the de-activation of the Financial Transaction Service in the 
Mobile Phone or connectable electronic device 
50 . Receiving, interpreting, decrypting, transaction related data files 
. Verifying digital signatures 

. Displaying data and information coming from the TPP such as but not limited to 
transaction confirmation, transaction denial, FTA balance or status, answer to request, 
update of FTA parameters, update of client software, etc... 

55 

The invention is also characterised by the fact that this software is loaded in a memory of 
the Mobile Phone or connectable electronic device, or in the memory of the SIM (or UIM, 
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or USIM) upon enrolment of the subscriber to the Financial Transaction Service. This is 
done usually at the Point Of Sale (POS) of the Telecom Operator by means of an 
appropriate connecting device between the POS and the Mobile Phone or connectable 
electronic device; or in the case of a SIM (or UIM or USIM) by means of card reader 
5 connected to the POS. 

In another embodiment of the invention, this software is already preloaded in the 
memory of the Mobile Phone or connectable electronic device, or of the SIM (or UIM or 
USIM); in such case it is only needed to activate the use of this software upon enrolment. 
This is either done directly at the Point Of Sale by inputting manually an activation code, 
10 or by sending Over The Air from TPP to the Mobile phone such activation code. 

In another embodiment of the invention, this software is downloaded Over The Air from 
the TPP directly to the Mobile Phone or connectable electronic device or the SIM (or UIM 
or USIM), and activated automatically upon enrolment of the subscriber to the Financial 
Transaction Service. 

15 

The invention is characterised by the fact that the MTMS contains or manages a file of 
parameters which represents the terms and conditions mentioned in the FTA Agreement, 
as well as the current balance and/or credit limit of the FTA. 

The invention is also characterised by the fact that MTMS compares transaction data 
20 against those parameters before a transaction order is sent to TPP. 

This file can be updated regularly and in particular when there are changes in the 
parameters or balance of FTA. 

This is particularly interesting as the MTMS can make a series of validity checks on the 
transaction as it is prepared by the subscriber and prompt the subscriber for changes if 
25 the transaction data he has input is incompatible with his FTA situation. This has also the 
advantage of reducing the load on the data network and on the TPP, by avoiding that 
invalid transactions are sent to TPP. 

Transmission of transactions related data and information 

30 

This invention is characterised by the fact that the transfer of data related to financial 

transactions and information between TPP and mobile phones or connectable electronic 

devices (either way) is using one or several types of data channel which exist in wireless 

communication networks. 
35 In digital wireless telecom systems several data channels are available and more are to 

come in the future. For illustration and simplicity purposes, the example of GSM is taken. 

GSM or UMTS system can provide several data channels like: 

USSD: Unstructured Supplementary Service Data 

HSCSD: High Speed Circuit Switched Data 
40 SMS: Short Message Service 

GPRS: General Packet Radio System 

EMS: Enhanced Message Service 

MMS: Multimedia Message Service 

45 All those data channels have different characteristics, capabilities, advantages and 
drawbacks. Also mobile phones do not necessarily support all six above mentioned 
channels; as of today all GSM mobile phones support USSD and SMS while only newer or 
future phones support GPRS, EMS or MMS. 

This invention is characterised by the fact that at each time TPP needs to send 
50 transaction related data or information to a mobile phone or connectable electronic 
device; it will select the most suitable data channels to be used. The system can use one 
or several data channels for one transfer and the choice of the data channels will depend 
on the several considerations such as but not limited to: 
. Type and capabilities of mobile phone or connectable electronic device, 
55 . Is the mobile phone "power ON" or "power OFF"? 
. Time 

. Data channels or network load 
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. Actual location of mobile phone 
. Priority 

. Amount of data or size of file 

. Whether the data is encrypted or not 

5 

This invention is also characterised by the fact that each time the mobile phone or 
connectable electronic device needs to send transaction data or data request; the MTMS 
will select the most suitable data channel to be used. The choice of the data channel will 
depend on the several considerations such as but not limited to: 
10 . Type and capabilities of mobile phone or connectable electronic device 
. Time 

. Instruction from TPP 

. Data channels or network load 

. Priority 

15 . Amount of data or size of file 

. Whether the data is encrypted or not 

Methods for executing financial transactions 

20 This invention is characterised by the fact that the financial transactions are initiated 
and/or executed by the subscriber with his Mobile Phone or connectable electronic device 
duly loaded with the software (MTMS) described above, and following the methods 
described below. 

The main types of financial transactions are generally payment transactions; those 
25 transactions can be implemented and executed in a large variety of ways. For the 
purpose of understanding the invention the following description is limited to a few ways 
only, which are called transactions scenarios, and probably represent the most frequently 
encountered situations. 

30 Transactions Scenarios 

Each scenario involves a payer (B) who wants to send a payment to a payee (A) who 
receives such payment. In some cases "A" initiates the process by sending "B" a 
payment request. 

35 

Scenariol: Payer (B) generates a Payment Order (PO) in favour of the Payee (A), without 
any intervention from "A". 

Scenario2: Payee (A) generates and sends a Payment Request (PR) to the Payer (B); "B" 
40 receives the PR, and in case of acceptance generates a Payment Order (PO) in favour of 
"A". 

Both the Payer and the Payee have signed a FTA agreement with the same Telecom 
Operator, have their own Financial Transaction Account, and can benefit from the 
45 Financial Transaction Service provided by the Telecom Operator. Both, "A" or "B" can be 
individuals, shops, or organisations (companies, associations, clubs, etc.). 

Transaction process 

50 For illustration purpose and simplicity, the process below is described, using the GSM 
system which is the most widely used digital mobile telephone system in the world to 
date. 

Scenariol: Simple payment scenario 

55 

A Payer (B) wants to pay the Payee (A) an amount of X $ with his Mobile Phone or 
connectable electronic device and thanks to the Financial Transaction Service. Because 
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"B" knows "A" or is able to identify "A" by his Mobile Phone Number or his FTA Number, 
"B" will generate and send a Payment Order (PO) of value X $ to "A". 
This is a very common scenario of someone who wants to send money to a parent or a 
relative; or someone who wants to pay bill (electricity, phone, rent, etc.); or who wants 
5 to make a donation as mentioned above. 

This invention is characterised by a method of generating a Payment Order directly from 
the Mobile Phone or connectable electronic device, sending the Payment Order to the 
Transaction Processing Platform, having the TPP process, execute the payment to "A", 
10 confirm execution of such payment to "A" and "B". The method is decomposed in few 
steps that are further described below. 

This invention is also characterised by the fact that a payment transaction can be made 
anonymous. In this case the Payee will receive the payment without knowing who the 
15 Payer is. The advantages of such possibility are obvious. 

This invention is also characterised by the fact that the payment execution date and time 
can be chosen by the payer. 

20 Step 1: "B" prepares and signs the payment order (PO) 

For this purpose "B" activates on his handset, through a menu selection, the Financial 
Transaction function. This is easily enabled with a SIM Tool Kit (STK) menu in the GSM 
system. 

25 The handset displays a screen and prompts "B" to enter the following data: 

Payee N°: "A" Mobile Phone Number or "A" FTA Number, (15812345678 in Figure3) 
Amount $: X (1,238.88 in Figure 3) 
Anonymous: Y or N (for YES or NO) 
30 Priority: (priority level) 
Object: (optional) 
Comments: (optional) 

Once "B" has keyed in all the data required, he presses the YES key on his handset to 
35 finish the PO input. The MTMS then makes a series of checks, such as but limited to: 
. Check Mobile Phone Number or FTA Number format 

. Check the amount X to be paid against FTA balance and/or credit limit, and other FTA 
agreement parameters. 

If the data input by "B" is found valid by MTMS, the handset displays a new screen with 
40 the data concerning the PO, and adds a PO number "wxyz", then prompts "B" to validate, 
confirm and sign. 

If this not the case, the MTMS displays an alert, or generate an audible message 
requiring "B" to modify his PO. This can be for example the amount X $ which is beyond 
45 FTA agreement authorised limit, etc... 

Validation/Confirmation/Signature is done by keying a password (string of alpha and/or 
numeric characters) which is kept secret by "B". In another embodiment of the invention 
the Validation/Confirmation/Signature of the PO is triggered using another authentication 
50 mean depending on the capabilities of the handset or connectable electronic device. 
Such means can be: 

. Finger print recognition, if the handset is equipped with a finger print sensor. 
. Voice authentication, if a voice authentication algorithm can run on the handset. 
. Face recognition, if the handset is equipped with digital camera and a face 
55 authentication algorithm is installed 

. Any other authentication method, using a biometric means or not, could also be 
envisaged. 
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Once Validation/Confirmation/Signature is done, "B" has nothing more to do. 
Step 2: Sending the Payment Order to TPP 

5 

This invention is characterised by the fact that, once Validation/Confirmation/Signature is 
done by "B", the MTMS in the handset generates a data file (POB(x,A)) with the data of 
the PO, and date & time on which it has been validated. 

This invention is also characterised by the fact that the MTMS generates a digital 
10 signature (DS(POB)) of POB(x,A), using a crypto algorithm and a secret key that are 
available in a memory of the handset or connectable electronic device. They can be the 
algorithm and the secret key that are used by the telecom network to authenticate the 
Mobile Phone; or they can be a Financial Transaction dedicated algorithm and key. 

15 In another embodiment of the invention, the Telecom Operator uses a Public Key 
Infrastructure (PKI), and provides each FTA subscriber with a Private and a Public key 
which are securely stored in a memory of the Mobile Phone or connectable electronic 
device or in a memory of the SIM. A public key algorithm is used by MTMS and TPP for 
the purposes of generating digital signatures, encrypting transactions data files, 

20 decrypting same files, verifying digital signatures, etc... 

In another embodiment of the invention, the crypto algorithm and the key are stored in a 
secure memory of the SIM, and the SIM processor generates and/or verifies the digital 
signature. 

25 Once the digital signature is generated, MTMS selects the most suitable data channel (as 
mentioned above), format the file according to the data channel selected and send 
through the data channel the data file (POB(x,A) together with the digital signature 
DS(POB) to the Transaction Processing Platform (TPP). 

In another embodiment of the invention the data file (POB(x,A) is encrypted using the 
30 same algorithm and key as the ones used in the digital signature generation; or in the 
case of use of a PKI, the data file will be encrypted using the public key of TPP. 

The data file (PO B (x,A) is at the same time stored in the memory of the handset or the 
memory of the SIM. 

35 

Step 3: Processing of the Payment Order by TPP 

Once the data file POB(x,A) with the corresponding digital signature DS(POB) are 
received by TPP; TPP is able to detect the originator as being "B". 
40 TPP verifies the digital signature DS(POB) (as being generated by "B" and applied to 
POB(x,A)), this permits to authenticate "B" as the actual originator of the PO. 
TPP adds a time stamp (date & time) generated by TPP's own internal clock, and extracts 
the data of the Payment Order sent by "B". 

TPP sends back to "B" an acknowledgement message whose form will depend on the 
45 priority selected by "B". Following is an example of message sent and that will be 
displayed on the handset screen: "your PO N° wxyz has been received, execution result 
will sent to you soon. Thank you." 

If the data file has been encrypted, then the first operation realised by TPP is to decrypt 

the file with the appropriate algorithm and key. 
50 Then TPP executes a series of checks in order to validate and execute the transaction. 

TPP verifies if the Payee "A" designated by his Mobile Phone Number or his FTA Number 

is actually a FTA subscriber or not. TPP then checks the situation of "B" FTA parameters 

contained in the FTA agreement against the amount X $ to be paid to "A" (current 

balance, overdraft, credit limit, transaction limit, etc. ). 
55 After those validity checks have been performed on the PO sent by "B" in favour of "A", 

TPP is able to authorise or deny the transaction, and two situations may occur: 

- Transaction is authorised 
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- Transaction is denied 

1- Transaction is authorised 

5 This invention is characterised by the fact that TPP processes the transaction, and 
accomplishes the following operations: 

TPP debits the amount of the PO i.e. X $, from "B" FT A. 

TPP debits an amount Y $ (1.24 $ in Figure 3 screen 8) corresponding to the transaction 
10 charge (if any) from "B" FT A. This transaction charge is defined in the FTA agreement 
between the Telecom Operator and "B". 
TPP credits the amount X $ on "A" FTA. 

TPP debits an amount Z $ (1.48 $ in Figure 4 screen 11) corresponding to the transaction 
charge (if any) from "A" FTA. This transaction charge is defined in the FTA agreement 
15 between the Telecom Operator and "A". 

After those debit and credit operations the balances of each FTA become: 
For "B" -> BalanceB2 = BalanceBl - X - Y. 
For "A" -> BalanceA2 = BalanceAl + X - Z. 
20 TPP generates a Transaction Number to identify this transaction. 

TPP credits Y+Z to the Telecom Operator's Transaction fees account. 

In another embodiment of the invention, the transactions fees Y and/or Z are charged to 

the respective phone bills of "B" and/or "A". 

25 Step 4: Confirming transaction execution to XX B" 

This invention is characterised by the fact that, TPP generates a Transaction Confirmation 
Notice to "B" and containing the following data: 

- Transaction Number (B21669 in Figure 3, screen 6) 
30 - PO Number 

- Date & time of transaction execution (2002.04.28-18:58:48 in Figure 3 screen 6,7) 

- Payee: "A" Mobile Phone Number or FTA Number 

- Amount: X $ 

- Transaction Charge: Y $ 

35 - New FTA balance: BalanceB2 (4,512.12 $ in Figure 3 screen 8) 

- If payment is anonymous: YES or NO 

- Object of the payment (as sent by B) 

- Comments (as sent by B) 

40 The data concerning this Transaction Confirmation Notice is formatted by TPP according 
to the data channel that is used and sent to the Payer "B". 

In another embodiment this data is encrypted with the relevant algorithm and key, and 
sent to "B". 

"B" can display this Notice on the screen of his handset or connectable electronic device. 
45 This notice is also recorded in a memory of his handset or a memory of the SIM; the 
record of Payment Order is then erased. 

The memory in the handset or in the SIM is configured in such a way as it can record 
several transactions made by "B". This enables W B" to check the accuracy of the 
statement of account provided to him by the Telecom Operator on a regular basis. 

50 

Step 5: Sending Payment Advice to "A" 

The invention is characterised by the fact that TPP generates a Payment Advice to "A" 
with the following data: 
55 - Transaction number 

- Date & time of transaction 

- Amount received: X $ 
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- Transaction Charge: Z $ 

- New FTA balance: BalanceA2 (11,236.40 $ in Figure 4 screen 11) 

Payer: "B" Mobile Phone Number or FTA Number or undisclosed (if anonymous) 

- Object: (as sent by "B") 

5 - Comments: (as sent by "B") 

TPP first sends an alert to "A" to inform "A" of a receipt of a Payment. Following is an 
example of alert: "You have received a payment of X $ on your FTA. Please see details of 
transaction in the Payment Advice." 

10 

The data concerning this Payment Advice is formatted by TPP according to the data 
channel that is used and sent to the Payee "A". 

In another embodiment this data is encrypted with the relevant algorithm and key, and 
sent to "A", and reciprocally decrypted by the MTMS on "A" handset. 
15 "A" can display this Notice on the screen of his handset. This notice is also recorded in 
the memory of his handset or of the SIM. 

The memory in the handset or in the SIM is configured in such a way as it can record 
several transactions received by "A". This enables "A" to check the accuracy of the 
statement of account provided to him by the Telecom Operator on a regular basis. 

20 

Step 6: Recording the transaction in TPP 

This invention is characterised by the fact that, TPP records in a log of transactions, all 
the transaction details (Transaction number, date & time of receipt of PO from "B", PO 

25 number, date and time of execution of the transaction, Payer (B) Mobile Phone Number 
or FTA Number, Payee (A) Mobile Phone Number or FTA Number, amount paid X $, if 
payment anonymous or not, priority, Object of the payment (as sent by B), Comments 
(as sent by B), transaction charge on "B": Y $, transaction charge on "A": Z $; date & 
time of confirmation to "B" and data channel used; date & time of confirmation to "A" 

30 and data channel used, Digital signature). 

This log is particularly useful for the management of all the Financial Transaction 
Accounts, and for accounting purposes. 

2- Transaction is denied 

35 

This invention is characterised by the fact that, TPP sends immediately an alert to "B", 
through the quickest data channel, to notify him that his Payment Order N°wxyz is 
rejected and the reason for denial. The alert will be displayed on the handset of the Payer 
(B). 

40 As an example such alert could have the following form: "Your PO N° wxyz for amount X 
$, is rejected. Reason: your overdraft will pass authorised limit. Please contact your FTA 
adviser." 

No debit or credit is made on "B" and "A" Financial Transaction Accounts; no advice is 
45 sent to "A". 

The PO recorded in the memory of "B" handset, or in the memory of the SIM, is updated 

with the mention "Rejected: date & time". 

The PO details are registered in a log of rejected transactions. 

50 Scenario2: Payment with preliminary request from the Payee 

In this scenario the Payee (A) is addressing a Payment Request (PR) via the TPP to the 
Payer (B). 

This can, for example happen in a retail shop, where the shop keeper is interested to 
55 receive a payment directly on his FTA. 

This obviously supposes that "B" had previously given his Mobile Phone Number or his 
FTA Number to "A" by whatever mean. 
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To generate the Payment Request "A" will activate the adequate function on his mobile 
phone through a menu selection. This is generally enabled with SIM Tool Kit (STK) menu 
in the GSM system. 

The handset displays a screen and prompts "A" to enter the following data: 
5 Payer N°: "B" Mobile Phone Number or "B" FTA Number 
Amount $: X 
PR N°: abcde 
Object: (optional) 
Comments: (optional) 

10 

Once the PR input is finished "A" activates the send command. The MTMS of "A" handset 
select the most appropriate data channel, creates a file formatted for this data channel 
and send the file to TPP. Upon receipt of this file TPP recognises that it is a Payment 
Request sent "A" and destined to "B". TPP makes a preliminary verification to determine 
15 if such potential transaction may be authorised or not and sends an alert to "B". 

If transaction could be authorised: this alert will contain all data concerning the PR, and a 
mention that a corresponding Payment Order could be authorised. The alert is then sent 
to "B" through the appropriate data channel, and displayed on "B" handset. 
20 As an example this alert could have the following form: 

Payment Request: 

From: "A" Mobile Phone Number or "A" FTA Number 
Amount: X $ 
25 PR N°: abcde 
Object: "text..." 
Comments: "text..." 

This transaction can be authorised! If you want to pay press YES 

30 By pressing YES "B" gets automatically a Payment Order fully ready on his handset or 
connectable electronic device, for him to Validate/Confirm/Sign as described earlier in 
scenariol. Then the process continues as described in scenariol. 

If transaction could not be authorised: alerts are sent immediately to both "B" and "A" 
35 mentioning that a payment transaction corresponding to the PR sent by "A" would not be 
authorised. 

As examples the alert could have the following form: 

Alert to "A": "Sorry the transaction referring to your PR N° abcde to "B" would not be 
40 authorised!" 

Alert to "B": "you have received a PR N° abcde, for X $, from "A". This transaction will 
not be authorised. Reason: your FTA balance is not enough." 

45 This method has several advantages for both the Payer and the Payee. 

It permits the Payee to get an immediate feedback from TPP to know whether the Payer 
can actually pay the amount requested. 

It is also very convenient for the Payer, since the PO can be generated automatically with 
the data received from the PR. As such the Payer does not need to spend time inputting 
50 the data to prepare the PO; he just has to Validate/Confirm/Sign it. 

In another embodiment of the invention the Payment Request (PR) may be sent directly 
from "A" to "B" through a messaging service (SMS, EMS, MMS, or other) without 
transiting through TPP. In this case no preliminary verification can be made by TPP; and 
55 no alert can be sent either. 
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In this case "A" generates a specially structurea Message using the corresponding feature 
of MTMS. 

One form of the Message can be as follows: 
Hello, please pay: "X $" 
5 To: "A" Mobile Phone Number or FTA Number 
PR N°: abcde 
For: "object" 
Comments: "text if any" 

10 This Message is directly sent to "B". 

Upon receipt, such Message is recognised by "B" handset MTMS as being a Payment 

Request and is displayed in such a way to enabled simple and quick answer from "B". 

"B" has just to press the YES or NO key of his handset to start generating the 

corresponding Payment Order in favour of "A". 
15 In case of acceptance from "B", "B" can generate a Payment Order in exactly the same 

way as in scenariol; but in this case "B" does not need to key in all the data required to 

generate the Payment Order as he can retrieve it from the Message containing the 

Payment Request sent by "A". 

20 Other transaction scenarios 

For the purpose of illustrating and allowing a good understanding of the invention, two 
main transaction scenarios have been described in details. This invention is characterised 
by the facts that it allows implementing other transaction scenarios such as but not 
25 limited to: 

- Differed payment, transaction scenario: this is similar to scenariol, but actual payment 
(i.e. debit and credit operations) is executed at a latter date than the Payment Order. In 
this case the payer adds in his PO, the execution date on which payment should be made. 

30 This can be interesting for the payment of bills on fixed date (electricity bill, apartment 
rent, phone bill, etc.). 

- Differed payment with Payment Request, transaction scenario: this is similar to 
scenario2 but with a differed payment as described above. 

35 

- Conditional payment, transaction scenario: this generally a differed payment scenario 
where payment is actually executed when a set of conditions are met. Conditions could 
be met by "A" and/or "B" or by a third party "C". This can be interesting in such 
situations where the payer agrees to pay only upon or after successful delivery of goods 

40 or services. 

This can be illustrated by the following example: 

"B" buys books to "A"; the books will be delivered by mail, and "B" agrees to pay only 
upon receipt of the books. The condition for payment will then be the confirmation of 

45 delivery by the Post Office (C). In this case "A" will emit a PR that will be accepted by "B", 
who will emit the corresponding PO in the same as described in scenario2. However 
payment will be executed by TPP only upon confirmation of receipt of the books. On the 
occasion of the delivery "C" sends to TPP a Delivery Confirmation Notice (DCN) with the 
following data: 

50 DCN N°: 123456 

Sender: "A" Mobile Phone Number or FTA Number 
PR N°: abcde 

Receiver: "B" Mobile Phone Number or"B" FTA Number 
Goods received on: date &time 

55 

Upon receipt, TPP sends this DCN to "B". "B" receives this notice that he can display on 
his handset or connectable electronic device and in case of acceptance, 
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Validates/Confirms/Signs by keying in his password in the same way he is doing for the 
PO. This will have the effect of generating a digital signature of the DCN. The DCN 
together with its digital signature are then sent by "B" back to TPP. Upon receipt TPP 
sends a message to "C" and "A" informing about the receipt and acceptance of the books 
5 by "B" and execute the payment in favour of "A". 

Special lines and accounts 

Shop keepers or store owners who are interested to offer their clients the possibility to 
10 pay through the Financial Transaction Service provided by the Telecom Operator might 
not be willing to pay for one or several Mobile Phone subscriptions and associated 
Financial Transaction Accounts, that will actually never be used for voice calls. 

This invention is characterised by the fact that the Telecom Operator provide Mobile 
15 Phone lines where the voice capability is de-activated and where only data channels will 
be usable. Those Mobile Phone lines can also be given numbers that make them clearly 
recognisable by the public as data only lines or even Financial Transaction only lines. For 
example in China, mobile phone numbers often start by 3 distinguished digits like 139, 
138, etc... The "data only" mobile phone numbers could be given first 3 digits like 839, 
20 838, etc... 

Generally point of sales in stores, only receive payments (this is their main function) and 
seldom or never need to make any payments. It can also be very convenient, for store 
owner, that the Financial Transaction Accounts associated with the point of sale terminal 
25 are configured in such a way that they can only RECEIVE payments, and not be able to 
make any payment. 

This invention is characterised by the fact that the Telecom Operator limits the 
possibilities of certain Financial Transaction Accounts, such as but not limited to: 
receiving payments from third only, and not emitting payments to third parties. 

30 

The invention being thus described, it will be obvious that the same way be varied in 
many ways. Such variations are not to be regarded as a departure from the scope of the 
invention, and all such modifications as would be obvious to a person skilled in the art 
are intended to be included within the scope of the following claims. 
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CLAIMS 

1. A system, enabling subscribers of a wireless Telecom Operator to execute financial 
transactions with a mobile phone, or an electronic device which can be connected to the 

5 wireless communication network, 
Characterised in that 

A subscriber has one or several Financial Transaction Accounts open and managed by 
the Telecom Operator, which can receive monetary deposits, and on which debit and 
credit operations can be executed, 

10 

And comprising 

- A Transaction Processing Platform which is a software system running on the 
existing computers of the Telecom Operator or on dedicated computers, and 

which is interfaced, at least with the subscribers' data base, the wireless 
15 communication network or some data channels of the wireless communication network, 
the accounting system, and other different elements of the Telecom Operator 
infrastructure; 

which manages the financial transaction related movements and operations, for 
example debits, credits, transaction confirmations, statement of account, reporting; 
20 which sends / receives, through the wireless communication network, to/from the 
mobile phones or connectable electronic devices, transaction related data or other 
information, 

- a client software program which can run on a mobile phone or a connectable 
electronic device to the wireless communication network or on the Subscriber Identity 

25 Module (SIM for GSM, or UIM for CDMA or USIM for UMTS, WCDMA, or equivalents, etc..) 
inserted in the mobile phones or the connectable electronic device, 
functions of the client software comprising: 

allowing authentication of the subscriber through password input or other means; 

enabling capture or validation and display of financial transaction related data; 
30 enabling to send, receive financial transactions related data or financial transaction 
account information, through the wireless communication network, or through some 
specific data channels of such network. 

2. A system according to claim 1, characterised in that each Financial Transaction 
35 Account is associated to one wireless phone line. 

3. A system according to claim 1 or 2, characterised in that the Financial Transaction 
Account number is the same as the Mobile Phone number. 

40 4. A system according to claim 1 or 2, characterised in that the Financial Transaction 
Account number is different from the Mobile Phone number. 

5. A system according to any one of above claims, characterised in that the terms and 
conditions of use of a Financial Transaction Account are appointed in advance (the 

45 Financial Transaction Service agreement) between a subscriber and the Telecom 
Operator. 

6. A system according to claim 5, characterised in that the Financial Transaction Account 
is restricted to receiving payments but not emitting payments. 

50 

7. A system according to any one of above claims, characterised in that the wireless 
phone line associated to a Financial Transaction Account has its voice communication 
capability de-activated, keeping only data channels. 

55 8. A system according to claim 3, characterised in that a Financial Transaction Account is 
merged with Mobile Phone subscription account in one single account. 
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9. A system according to any one of above claims, characterised in that the client 
software is pre-loaded or pre-existing in a memory of the subscriber's mobile phone or 
connectable electronic device. 

5 10. A system according to any one of above claims, characterised in that the client 
software is loaded into a memory of the subscriber's mobile phone or of the connectable 
electronic device, upon opening a Financial Transaction Account by such subscriber. 

11. A system according to any one of claims 1 to 8, characterised in that the client 
10 software is pre-loaded in a memory of the Subscriber Identity Module. 

12. A system according to any one of claims 1 to 8, characterised in that the client 
software is loaded in a memory of the Subscriber Identity Module, upon opening a 
Financial Transaction Account by such subscriber. 

15 

13. A system according to claim 10 or 12, characterised in that the client software is 
loaded over the air through the wireless communication network. 

14. A system according to any one of claims 9 to 13, characterised in that the client 
20 software is activated or enabled upon opening a Financial Transaction Account by a 

subscriber. 

15. A system according to claim 14, characterised in that the activation of the client 
software is realised by the input of a specific code. 

25 

16. A system according to claim 15, characterised in that the specific code to activate the 
client software is sent over the air through the wireless communication network. 

17. A system according to any one of claims 9 to 16, characterised in that the client 
30 software can be executed by a microprocessor of the subscriber's mobile phone or the 

subscriber's connectable electronic device. 

18. A system according to any one of claims 9 to 16, characterised in that the client 
software can be executed by the microprocessor of the Subscriber Identity Module. 

35 

19. A system according to any one of claims 9 to 16, characterised in that the client 
software can be executed partly on a microprocessor of the subscriber's mobile phone or 
connectable electronic device, and partly on the microprocessor of the Subscriber 
Identity Module. 

40 

20. A system according to claim 17, 18 or 19, characterised in that the client software 
contains or can activate an encryption algorithm and/or a digital signature algorithm, 
using a subscriber specific, encryption key. 

45 21. A system according to claim 17 or 20, characterised in that for the client software, 
the encryption/decryption related operations or digital signature generation/verification 
are executed by the microprocessor of the Subscriber Identity Module. 

22. A system according to claim 20, characterised in that the subscriber encryption key is 
50 specific to the subscriber and to his Financial Transaction account. 

23. A system according to claim 17, 18 or 19, characterised in that the client software 
can create or read or update a data file, stored in a memory of the subscriber's mobile 
phone or of the connectable electronic device or of the Subscriber Identity Module, and 

55 containing parameters linked to the terms and conditions of use of the subscriber's 
Financial Transaction Account. 
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24. A system according to claim 23, characterised in that the data file comprises at least 
one of the following subscriber's Financial Transaction Account data: current balance, 
credit limit, minimum debit operation amount, maximum debit operation amount. 

5 25. A method used in a system, according to any one of above claims, by a subscriber to 
prepare or validate a financial transaction order on a mobile phone or a connectable 
electronic device and send it through the wireless communication network to the 
transaction processing platform, comprising 

capturing the transaction data with at least: the beneficiary (payee) number and the 
10 amount, 

validating the transaction data by inputting a password or by using another 
subscriber authentication mean, 

sending the transaction data through the wireless communication network. 

15 26. A method according to claim 25, characterised in that the transaction data is received 
from the beneficiary (payee). 

27. A method according to claim 25, characterised in that the capture of the transaction 
data is done orally. 

20 

28. A method according to any one of claims 25 to 27, characterised in that the 
validation is done by subscriber's finger print authentication mechanism on the mobile 
phone or the connectable electronic device. 

25 29. A method according to any one of claims 25 to 27, characterised in that the 
validation is done by subscriber's voice a authentication mechanism. 

30. A method according to any one of claim s 25 to 27, characterised in that the 
validation is done by subscriber's face authentication mechanism. 

30 

31. A method according to any one of claims 25 to 30, characterised in that the 
subscriber specifies a priority level. 

32. A method according to one of claims 25 to 31, characterised in that the subscriber 
35 specifies to remain anonymous. 

33. A method according to any one of claims 25 to 32, characterised in that the 
subscriber specifies the date and time of execution of the transaction. 

40 34. A method according to any one of claims 25 to 33, characterised in that the 
subscriber specifies conditions to be fulfilled for the actual execution of the transaction. 

35. A method according to any one of claims 25 to 34, characterised in that the 
validation triggers the generation of a digital signature of the transaction data. 

45 

36. A method according to any one of claims 25 to 35, characterised in that the 
validation triggers the encryption of the transaction data. 

37. A method according to any one of claims 25 to 36, characterised in that one data 
50 channel for sending the transaction data over the wireless communication network, is 

selected among several available channels. 

38. A method according to claim 37, characterised in that the selection of the data 
channel for sending the transaction data, is realised by taking into account at least one of 

55 the following parameters: Type and capabilities of mobile phone or of the connectable 
electronic device; Current date & time; Instruction from the Transaction Processing 
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Platform; Data channels or network load; Priority level; Amount of transaction data; 
Whether the data is encrypted or not. 

39. A system according to any one of claims 17 to 19, characterised in that the client 
5 software is able to realise the method according to one of claims 25 to 38. 

40. A system according to claim 39, characterised in that the client software compares 
the transaction data to the parameters contained in a file according to claim 24, and 
determines whether the transaction might be authorised or not. 

10 

41. A system according to claim 39 or 40, characterised in that the client software 
generates a transaction number, and adds to the transaction data such number as well 
as date & time of validation. 

15 42. A system according to any one of claims 39 to 41, characterised in that the client 
software formats the transaction data according to the data channel, which is selected to 
send such transaction data. 

43. A system according to any one of claims 39 to 42, characterised in that the client 
20 software sends the transaction data in encrypted form together with the digital signature 

to the Transaction Processing platform. 

44. A method used in a system according to any one of claims 1 to 24 and any one of 
claims 39 to 43, to process financial transactions emitted by a Financial Transaction 

25 Account owner (payer) in favour of another Financial Transaction Account owner (payee), 
on a Transaction Processing Platform, and comprising 

receiving through the wireless communication network the transaction order data 
validated and sent from the payer's mobile phone or connectable electronic device 
according to any one claim 25 to 43, 
30 analysing and comparing such data to payer's Financial Transaction Account situation, 
and terms and conditions of use, 

determining whether the transaction can be authorised or denied, 
authorising or denying the transaction, 

executing the transaction (if authorised): making a debit on payer's FTA of the 
35 amount of the transaction; making a credit on payee's FTA of the amount of the 
transaction, 

or denying the transaction and sending a denial notice to the payer; 
recording the transaction details in a transactions log. 

40 45. The method according to claim 44, characterised in that a transaction fee is debited 
from the payer's and/or the payee's Financial Transaction Accounts. 

46. A method according to claim 44, characterised in that a transaction fee is charged to 
the payer's and/or the payee's telephone bills. 

45 

47. A method according to any one of claims 44 to 46, characterised in that a 
confirmation of the transaction execution is sent to the payer through the wireless 
communication network. 

50 48. A method according to any one of claims 44 to 47, characterised in that a transaction 
advice is sent to the payee through the wireless communication network or through 
internet. 

49. A method according to any one of claims 44 to 48, characterised in that a time stamp 
55 is added to the transaction data upon receipt of a transaction order. 



17 



1/27/2010, EAST Version: 2.4.1.1 



WO 03/094491 



PCT/CN02/00301 



50. A method according to any one of claims 44 to 49, characterised in that a time stamp 
is added to the transaction data upon execution of a transaction order. 

51. A method according to any one of claims 44 to 50, characterised in that a unique 
5 number is allocated to each executed transaction. 

52. A method according to any one of claims 44 to 51, characterised in that the 
transaction order data is decrypted and/or the accompanying digital signature is verified 
using the appropriate key. 

10 

53. A method according to any one of claims 44 to 52, characterised in that some data 
sent by the Transaction Processing Platform to the Financial Transaction Accounts owners 
are encrypted and/or digitally signed. 

15 54. A method according to any one of claims 35 to 36 and one of claims 52 to 53, 
characterised in that encryption/decryption, and/or digital signature 
generation/verification are using a Public Key Infrastructure. 

55. A system according to any one of claims 1 to 24 and any one of claims 39 to 43, 
20 characterised in that the software system is able to realise the method according to claim 

44 or any one of the claims 45 to 54. 

56. A system according to claim 55, characterised in that the software system selects the 
most appropriate data channel of the wireless communication network to send 

25 transaction related data or account information to the Financial Transaction Account 
owners. 

57. A system according to claim 56, characterised in that the data channel selection 
process takes into account at least one of the following parameters: Type and capabilities 

30 of mobile phone or of the connectable electronic device; Actual location of the mobile 
phone or connectable electronic device; Current date & time; Data channels or network 
load; Priority level; Amount of transaction data; Whether the data is encrypted or not. 

58. A system according to claim 1 or any one of claims 9 to 23, characterised in that the 
35 software system is able to de-activate the client software by sending a de-activation 

instruction, through the wireless communication network to the mobile phone or the 
connectable electronic device. 
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Figure 2 : Scenariol - flow chart 



Step 1 



Step 2 



Prompt Payer for transaction (screenl) 

Prompt payer for Payment Order entry (screen 2) 

Payment Order data capture (screen 3) 

Payer Validates/Confirms/Signs with password entry (screen 4) 



PO N° creation 

Payment Order data file generation 

Generation of Digital Signature of PO data file 

Encryption 

Data channel selection 

Send PO data file to Transaction Processing Platform 



PO data file received by TPP 

Data file decryption 

Digital Signature verification 

TPP sends acknowledgement to Payer 



Step 3 



| Payer receives acknowledgement on Mobile Phone (screen 5) | 



TPP ckecks validity of transaction 



Transaction DENIED 1 



Ate rt sent tc Payer 



Step 5 



Transaction AUTHORISED 



Debit 1,238.88 $ from Payer's FTA 

Debit 1.24 $ on Payer's FTA for transaction fee 

Credit 1,238.88 $ on Payee's FTA 

Debit 2.48 $ on Payee's FTA for transaction fee 

Credit 3.72 $ on Telecom Operator Transaction fees account 

Generation of transaction N° : B21669 

Transaction date & time: 2002.04.28-18:58:48 



Payer receives transaction confirmation (screen 6) 
Details of transaction available (screen 7, 8) 



Payee receives Payment Advice (screen 9) 
Details of transaction available (screen 10, 11) 



Step 6 | Record Transaction details in transaction log 
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Figure 3 : Screen displays on Mobile Phone of Payer "B" 



.■ill 18:58 mD> 

Do you want to 
make a payment ? 



^ o o 



18:58 S3 
Payee N": _ 
Amount $: 
Anony: Priority: 
Object- 
Comment: 



^ o o 



.■ill 18:58 S3 
Payee N°:1 581 2345678 
Amount$: 1,238.88 
Anony: N Priority: 1 
Object: April rent 
^Comment: pis confrecpt^ 



o o o 



.■ill 18:58 S3 

Please validate, confirm, 
& sign by entering your 
password: ******* 



^ o o 



.alii 18:58 
Your payment order 
N° wxyz has been 
received, we process it! 



o o ^ 



v. 



,iil3 18 59 KD 
Your payment order 
N° wxyz has been 
executed, TrN°:B21669 
on 2002.04.28-18:58:48 



^ o o 



frfiil 18:59 »~ 
Payment O.N":wxyz 
TrN°:B21669 
on 2002.04.28-18:58:48 
Payee N°:1 581 2345678 
Amount$: 1,238.88 \ 



o o 



.sill 18:59 
Fee: 7.24 5 

FTA balance: 4,512.12$ 
Priority: 1 
Object: April rent 
Commentpls conf recpt 



^ o ^ 
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